home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000120_news@newsmaster….columbia.edu _Fri May 22 16:51:43 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  5KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA29012
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 22 May 1998 16:51:41 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA14045
  7.     for kermit.misc@watsun; Fri, 22 May 1998 16:51:41 -0400 (EDT)
  8. Path: news.columbia.edu!panix!nntprelay.mathworks.com!newsfeed.internetmci.com!4.1.16.34!cpk-news-hub1.bbnplanet.com!wtn-news-feed2.bbnplanet.com!news.bbnplanet.com!netnews.jhuapl.edu!usenet
  9. From: Skip Collins <collibf1@jhuapl.edu>
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 22 May 1998 16:47:51 -0400
  13. Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA
  14. Lines: 100
  15. Sender: collibf1@COLLIBF1
  16. Message-ID: <wk4syi58y0.fsf@jhuapl.edu>
  17. References: <35646665.EBB3868B@theriver.com> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu>
  18. NNTP-Posting-Host: collibf1-2.jhuapl.edu
  19. X-Newsreader: Gnus v5.5/Emacs 20.2
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:8773 comp.sys.hp48:81334
  21.  
  22. fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23.  
  24. > Most Kermit programs prefix all control characters by default when sending a
  25. > file.  Kermit 95 is the exception, since most Windows 95 users demand "high
  26. > performance".  Kermit 95's default is to unprefix a fairly safe subset of
  27. > control characters.
  28.  
  29. If I had to bet on what trips up most K95-HP48 connections I would wager it
  30. is control-char unprefixing. I will try it with mskermit when I get a
  31. chance. What command should I issue to mimic the K95 default?
  32.  
  33. > : I think the physical link is transparent to control characters. But perhaps
  34. > : the hp48 kermit software assumes prefixing.
  35. > : 
  36. > The cardinal rule of any communications protocol is "be conservative in
  37. > what you send, be liberal in what you receive".  The HP48 has it backwards.
  38. > There is no prohibition in the protocol definition against sending bare
  39. > control characters, 
  40.  
  41. This seems to contradict "Kermit: A File Transfer Protocol", 1987 ed.,
  42. which states on page 248, under the heading Encoding Summary: "Prefix
  43. encoding for control characters is mandatory."
  44.  
  45. > : The serial port is full duplex. The infrared port is only half-duplex
  46. > : because of optical feedback.
  47. > :
  48. > Does this apply to all models?  I got my information about dead periods in
  49. > the serial port from an HP engineer, circa 1990.
  50.  
  51. My information comes from HP and apparently applies to all HP48s. You
  52. might want to have a look at
  53. http://hp48.ml.org/programming/docs/ioguide.zip
  54.  
  55. Perhaps the dead time you mention is an artifact of a poor kermit
  56. implementation. If you believe HP, it does not seem to be a limitation
  57. of the hardware.
  58.  
  59. > Can you help clear this up?  What is the deal?  Text-mode transfers into
  60. > the HP-48 are the ones that get progressively slower?  But binary-mode
  61. > transfers into the HP-48 are OK?
  62.  
  63. Both are affected.
  64.  
  65. > Is it true that incoming text-mode packets are parsed as HP-48 programs?
  66. > So this means that only HP-48 programs may be sent in text mode, and any
  67. > other text files sent to the HP-48 are likely to be rejected.  One user
  68. > reported that any text file containing a "-" character would be rejected
  69. > for "Invalid syntax".
  70. > 
  71. > This means that non-HP-48-program files must be sent to the HP-48 in binary
  72. > mode, right?
  73.  
  74. The packets are parsed into an HP48 _object_, which might be a
  75. program, or might just be a string variable. I think it tries to parse
  76. the incoming stream as if it were being keyed in. So, [1 2 3], if sent
  77. in text mode would become vector. If the syntax of the sent object
  78. does not make sense as a keyed-in object, it becomes a string.
  79.  
  80. >   set carrier-watch off  ; (Does the HP-48 assert DCD? If so, use ON.)
  81.  
  82. It has no hardware flow control, if that's what you mean.
  83.  
  84. >   set flow none          ; (or Xon/Xoff)  
  85.  
  86. Should be none.
  87.  
  88. >   set control prefix all ; (Don't send bare control chars)
  89.  
  90. Until I see that unprefixing works, I should assume not.
  91.  
  92. >   set receive timeout 99 ; (see Note 1 below...)
  93. >   set send pause 100     ; (see Note 2 below...)
  94.  
  95. I don't think these are needed, your notes notwithstanding. I very
  96. rarely see packets retransmitted, which one might expect if there were
  97. a serious turn-around problem.
  98.  
  99. >   set file type text     ; For HP-48 programs
  100.  
  101. Most programs people download to their calcs are compiled
  102. binaries. They would be corrupted in text mode. Simple user-rpl
  103. programs, such as one might key into the calc itself, can be
  104. downloaded in text mode.
  105.  
  106. >   set file type binary   ; For all other forms of data
  107.  
  108. This is what I use almost exclusively. All the great freeware software
  109. out there should be downloaded this way.
  110.  
  111. > Oh, by the way, another peculiarity I noticed...  If the HP-48 is set up to
  112.  
  113. As long as you are cataloguing peculiarities, the HP48 sends packet
  114. sequence numbers that are larger than 63. One can compensate by doing
  115. mod63 before verifying. Is this right?
  116.  
  117. Another place to get more information is the hp48 faq:
  118. http://www.engr.uvic.ca/~aschoorl/faq/48faq-6.html
  119.  
  120. > - Frank
  121. Skip